InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/osinsap/90may.min

Text File | 1993-02-17 | 7KB | 165 lines

CURRENT_MEETING_REPORT_


Reported by Philip Almquist/ Consultant

General Issues


  1. How is what we do constrained by existing GSA procedures?  Not
     much, apparently, since GSA will probably modify their planned
     procedures if NIST so recommends.
  2. Where should the output of this group go?  An RFC, most likely, and
     we should (and probably can) also get it into the GOSIP User's
     Guide.
  3. Have we gotten foreign comments on the draft paper?  Basically, no.
     This may not be problem since most foreign sites may want to get
     NSAP addresses from their national authorities rather than the
     Internet.  However, comments from non-US members of the Internet
     are encouraged.


Discussion of the Draft Document

Unfortunately, a number of the attendees had been unable to read the
paper carefully beforehand, because it was distributed in Postscript
that didn't seem to be printable on some printers.  The chair promised
that this problem would be resolved before the next meeting.

Mary Youssef noted that the document did not adequately address how
large routing domains should be or will be; nor does it discuss how
interdomain routing will be accomplished.  It is crucial to understand
these issues if we want to design a scheme that will be practical given
the political and technical realities of the Internet.  Desire for local
autonomy will provide a push towards small routing domains (similar in
size to IP autonomous systems), whereas the current lack of an
interdomain routing protocol will provide a push towards very large
routing domains (for example, a regional network and its members might
form a single routing domain).  Ross Callon suggested that we were
overreacting to the lack of an interdomain routing protocol because
Internet deployment of OSI would be slow enough that static interdomain
routing would work until OSI has a real protocol for this purpose.  Tony
Hain disagreed, noting that DOE will have 50-100 routing domains once
they deploy DECNet Phase V. Rob Hagens spoke strongly against making
kludges in our design for the sake of short term workability.

Someone pointed out that, for NSAP assignment, we should be concerned
about the size of administrative domains rather than routing domains.
An ``administrative domain'' is one or more routing domains that share
the same NSAP address prefix.  Thus, it is the size and distribution of
administrative domains that determines how large the Internet can grow
before it collapses under the weight of the amount of information that
must be carried around in the interdomain routing protocol.  It was
pointed out that the term "administrative domain" is a politically

                                   1






unwise choice of wording, since it suggests that members of an
administrative domain have to cede administrative control of their
networks to the administrative domain, when in fact the only thing that
has to be centralized is the allocation of blocks of NSAP addresses.

For example, a regional network could obtain a block of NSAP addresses
and become an administrative domain, allocating chunks of its block of
NSAP addresses to individual campuses.  The regional would only have to
advertise to backbone networks its single block of NSAP addresses (via a
single prefix), rather than one or more per campus as is done in the IP
world.  However, there are some cases where a campus might have a good
reason to use NSAP addresses that were not from the regional's block of
addresses, but regionals could (and probably should?)  charge extra for
advertising these addresses to national backbones to discourage address
entropy and the resultant excessive growth of routing information in the
Internet.  However, we need to be sure that we don't create policies
which have the side effect of making it expensive for a campus to switch
WAN providers without immediately changing the NSAP addresses of all its
hosts.

The discussion returned to what seems to be the central issue:
information explosion.  There are two approaches:


   o minimize the size of the routing information that needs to be
     conveyed
   o devote more, faster hardware to exchanging routing information


We need to find the proper balance between these two approaches.  Ross
Callon suggested that most sites will be Internet leaf nodes, so we
probably win the most by collapsing data near the leaves of the tree.
However, for sites which are very small (and there will be a lot of
them) not much collapsing will be possible at the the leaf boundary, so
we'll need to have further collapsing farther up the tree to get
effective size reduction of the routing data about small sites.

It was pointed out that the paper uses a stylized model of the Internet
(backbones, regionals, and campuses), that ignores such real world
realities as back doors, mid-level networks which are not regionals (eg,
CSNET), etc.  It isn't immediately clear whether the stylized model
leads us to the right conclusions.  Tony Hain will try to write up a
more realistic model.

The issue of how mobile hosts fit into an essentially geographical
addressing scheme was brought up and quickly dropped because nobody has
a good answer.

The issue of whether we need a temporary interdomain routing protocol
for the Internet was discussed and deferred to OSI Area Directors and
the OSI General Working Group.  A draft version of BRP was suggested as
a likely candidate.

                                   2






Paul Tsuchiya presented his draft paper, ``Efficient Routing Hierarchies
Using Multiple Addresses''.  This paper describes a hierarchical address
allocation scheme which very strictly mirrors the hierarchical Internet
topology.  Since a host's address largely determines the route used to
get to it, hosts which are accessible via multiple regionals or
backbones may be assigned multiple addresses, providing alternate path
routing and a primitive form of policy-based routing.  The group seemed
to find the approach interesting but did not reach a firm conclusion
about its applicability.

It was agreed that once we start to understand how to do address
assignment and run OSI in the Internet we need to somehow disseminate
this knowledge to the managers of at least the mid-level networks.  One
good way to accomplish this might be a tutorial and discussion session
at a future IETF meeting.

ATTENDEES

    Philip Almquist           [e-mail]
    Lan Bosack                [e-mail]
    Ross Callon               [e-mail]
    Allan Cargille            [e-mail]
    Martina Chan              [e-mail]
    A. Lyman Chapin           [e-mail]
    Richard Colella           [e-mail]
    Curtis Cox                [e-mail]
    Ella Gardner              [e-mail]
    Martin Gross              [e-mail]
    Robert Hagens             [e-mail]
    Tony Hain                 [e-mail]
    David Miller              [e-mail]
    Cyndi Mills               [e-mail]
    Mark Needleman            [e-mail]
    John Vollbrecht           [e-mail]
    Dan Wintringham           [e-mail]
    Richard Woundy            [e-mail]
    Mary Youssef              [e-mail]



                                   3